Method, systems of devices, and computer program product for the document-related extension of a resource-structured document data flow

ABSTRACT

In a method and system for enhancement of an input document data stream which comprises at least one input format file comprising format definitions and an input document data file structured in at least one of ranges and sub-ranges and containing variable data, the data stream is enhanced with finishing commands. In a control file, defining level structures that correspond to at least one of the ranges and sub-ranges of the input document data file. In a control file, associating the finishing commands with levels. Using the control file, the input format file and the input document data file the following are automatically generated by a computer program module. a) an output format file that contains the finishing commands in callable groups, and b) an output document data file containing the variable data and group calls associated by at least one of range-by-range and sub-range-by-sub-range.

BACKGROUND

The invention concerns a method, a device system and a computer programproduct for processing of a document data stream that containsstructured fields. A typical document data format of this type is theformat AFP™ (advanced function presentation). It is in particular usedin electronic print production environments, i.e. in data processing andprinting systems that process document data with a speed of up to a fewthousand pages per minute.

Such document production systems exhibit a high degree of automation.For example, a printing system with integrated quality checking isspecified in U.S. Pat. No. 6,137,967.

Various print data streams and printing systems are, for example,specified in the publication “Das Druckerbuch”, Dr. Gerd Goldmann(editor), Océ Printing Systems GmbH, 6th edition (May 2001), ISBN3-000-00 1019-X. The server system Océ PRISMApro is specified in chapter14. This flexible print data server system is, for example, suited totransfer print data from data sources such as a source computer—theprint data in a specific print data language such as line data, AFP, PCL(Printer Command Language), PostScript, SPDS (Siemens Print DataStream), or in the language LCDS developed by the company XeroxCorporation—to a print production system.

Details of the resource-structured document data stream AFP™ arespecified in the publication Nr. S-544-3884-02, published by the companyInternational Business Machines Corp. (IBM) with the title “AFPProgramming Guide and Line Data Reference”. This documentation is to beobtained via the address IBM Printing Systems Division, Dept. H7FE,Building 004M, Information Development, PO Box 1900, Boulder Colo.80301-9191 USA or via\http://publib.boulder.ibm.com/prsys/pdfs/54438842. pdf.

The document data stream AFP was further developed into theresource-structured document data stream MO:DCA™, which is specified inthe IBM publication SC31-6802-05 (April 2001) with the title “MixedObject Document Content Architecture Reference”. This document is alsoaccessible at the Internet addresshttp://publib.boulder.ibm.com/prsys/pdfs/c3168025.pdf. Details of thisdata stream, in particular the use of structured fields, are alsospecified in U.S. Pat. No. 5,768,488. In the framework of the presentspecification, no differentiation is made between AFP and MO:DCA datastreams.

AFP/MO:DCA data streams are frequently converted into data streams ofthe format Intelligent Printer Data Stream™ (IPDS™) in the course ofprint production jobs and transferred to a high-capacity printer in thisformat. Such a process is shown in U.S. Pat. No. 5,982,997.

In the specification “UP³I; Universal Printer Pre- and PostProcessingInterface,” Version 1.02 (July 2002), published by the companies DuploInternational Ltd., Hunkeler AG, IBM Corporation, Océ Printing SystemsGmbH and Stralfors AB, which can be downloaded as a file at the Internetaddress www.up3i.org, the most varied control commands are provided thatcan be used in the creation of a printed document to control variousdevices of a print production system such as printing devices anddevices upstream and downstream from these, such as unwinders, cuttingdevices, hole devices, gluing devices and binding devices. It is therebyprovided that such data are exchanged between the different devices,thus for example between a paper dispenser and a printing device.

On the pages 134 through 141 of the UP³I specification, examples arealready cited as to how commands for print pre- and post-processingdevices can be inserted into an AFP (MO:DCA) or IPDS data stream. Withthe UP³I extensions, AFP applications can now contain UP³I controlcommands that are transferred to a printer, whereby printer-specificdata formats such as IPDS can be used. The UP³I control data are therebyinitially mixed with the print data and are only separated from these inthe printer. The further devices of the print production system, i.e.pre- and post-processing devices for the print good (such as paperdispensers, unwinders, stackers, punchers, folders, cutters andbinders), can then be addressed via the UP³I interface.

New AFP applications can already be coded from the beginning such thatUP³I functions are used. This is different than in older AFPapplications. Such applications for standard expressions (such as, forexample accounting printouts or account statements), applied in part formany years, must be changed when they should use UP³I functions.

From the IBM publication NR. S544-5284-06, “IBM Page Printer FormattingAid: User's Guide”, 7^(th) edition, which is accessible athttp://publib.boulder.ibm.com/prsys/pdfs/54452846.pdf, a tool is knownwith which a user can provide an existing AFP document data stream or aformat definition resource file “Formdef” located in this document datastream with additional commands. This occurs via a control file in whichit is entered when what is known as a copygroup or medium map with aspecific name must be generated.

In this type of data enhancement, corresponding calls of the media mapmust respectively be stored in the file in which the variable data aresituated in order to be able to let the commands generated in theformdef file act on the variable data. This manual reprogramming of thedata stream can be a very complex event that is error-prone—primarilywhen a plurality (for example 3 or more) of copygroups are to be newlyinserted. The effort thereby resulting for the user is substantial, andthe danger of wrong inputs exists when media map calls are not correctlyupdated, for example not changed in synchronization with the entries inthe formdef file.

Furthermore, it can occur that one and the same original data stream areprocessed with various print production systems, and this with variousfinishing possibilities. The application must then be re-adapted for therespective configuration of the print production system, which can leadto unwanted time delays under production conditions.

In the patent application Nr. PCT/EP02/05299, which the applicantsubmitted on 14 May 2002 with the title “Method, device system andcomputer program system for processing of document data”, it isdescribed how auxiliary data (such as, for example, barcodes) can beautomatically inserted into a document data stream.

A conventional processing of an AFP print document data stream withoutsupport of finishing or UP³I functionalities is shown in FIG. 2. Thevarious processing steps show what an AFP application designer (user)has to do in order to create an application: by means of a formattingcomputer program 20 (which, for example, can be the previously mentionedPage Printer Formatting Aid (PPFA) tool by the company IBM or the SmartLayout Editor (SLE) specified in the Druckerbuch introduced above) and acontrol file 21 with corresponding formatting parameters, the usergenerates a formdef file (resource) 23 that contains a copygroup (mediummap) with the name ACCOUNT.

A print data file 22 that contains variable data is prepared by the usersuch that it is called the copygroup which has been applied with thecontrol file 21 with structured fields of the type invoice medium map(IMM) “IMM Account”, which stands between the variable data. Detailsregarding the structured field type IMM can be learned from thepreviously cited IBM document SC31-6802-05.

In the example shown in FIG. 2, the print data file contains accountstatement documents for two different customers of a bank. For the firstcustomer, the print data file 22 contains two account statements withrespectively 9 pages and 6 pages. For the second customer, an accountstatement document with 3 pages should be printed out. For this, theprint data file 22 and the formdef file 23 are supplied to a hostprinter driver 24 that (in step S3) forms a print data stream of theformat IPDS from both files and, if applicable, resource files such as,for example, fonts, with which a print data stream an IPDS-capableprinting system 25 is activated. In the illustrated example, theprinting system 25 is controlled from a first printer 26 in which thefront side of a web-form recording medium is printed and a secondprinter 27 in which the back side of the same recording medium isprinted with the respectively associated data.

In step S4, the previously cited documents are printed out, i.e. as afirst document 28 of the first printout of the first customer thatcomprises five individual pages, three pages as a second document 29 forthe first customer with the second account statement, and two pages as athird document 30 for the second customer.

The same application as shown in FIG. 1 is shown in FIG. 3, whereby itis manually extended with additional commands for print pre- orpost-processing devices as they are provided in the UP³I specification.In the case of FIG. 3, the finishing commands shrink-wrapping(shrink-wrap), page offset (left/right/shift) as well as documentstapling (corner staple) are provided that should be applied on theprinted print good or parts thereof. Using FIG. 3, it is described whichoperating steps are necessary when this goal is executed with thealready specified tool by the company IBM, “Page Printer Formatting Aid”(PPFA) or with the Smart Layout Editor (SLE) known from the applicant.

In step S5, a new form definition file is generated by the user as aresource file with the Page Printer Formatting Aid tool (see above) orwith the tool Small Layout Editor (SLE) that is specified in thepreviously introduced “Druckerbuch” by Océ Printing Systems GmbH. Theparameters are specified in a PPFA control file 31 (in FIG. 3, thecontrol file 31 is subdivided into a first part 31 a and a second part31 b merely for representation reasons). The control file 31 shows thatthree copygroups (medium map fields) are necessary in order to be ableto activate the desired finishing functions. The UP³I control commandsfor the welding, the offset, and the stacking are part of the new mediummap, for example OPERATION SHIFT and REFERENCE left for the offset.

The PPFS control file 31 generated in the step S5 uses the PPFA computerprogram 32 in order to generate in the step S6 a formdef file in whichare contained the copygroups (LI_ACC1, LI_ACC2 and RI_ACC1) defined inthe PPFA control file 31. These new medium maps replace the copygroup(medium map) ACCOUNT contained in the formdef file 23 in FIG. 1.

In addition to the changes in the formdef file 23, the user must modifythe print data file such that the structured fields Invoice Medium Map(IMM) are synchronized with the new medium map names. The user mustthereby replace the respective old IMM call with a correct new IMM callthat corresponds to the respective desired finishing operations. In theexample of FIGS. 2 and 3, different calls are henceforth inserted inplace of the respective identical calls 22 a, 22 b and 22 c “ACCOUNT”for the three documents 28, 29, 30: the call IMM LI_ACC1 34 a, wherebythe document is distributed and stapled to the left, is to be added tothe document 28 and the call IMM LI_ACC2 34 b, whereby the document isdeposited and stapled to the left, is to be added to the document 29.The call RI_ACC1 is to be added for the document 30, whereby thedocument is deposited and stapled to the right. This association mustoccur manually in the print data file when the print data file existsalready or has the structure 22 shown in FIG. 1. Otherwise, the printdata file would have to be completely newly generated via acorresponding application program, which is, however, verytime-consuming under the circumstances. For synchronization, it is thusnecessary that copygroups a) are present, b) have matching parametersfor formdef file in the data stream and c) their calls are situated atprecisely the right point of the print data stream.

In step S8, the formdef file 3 and the print data file 34 are in turnconverted by the host printer driver 24 from the AFP format into an IPDSprint data stream and sent to the IPDS-capable printing system 25. Thecommands, which apply to the pre- or post-processing devices (UP³Icommands) and that are contained in the medium map, are converted intocorresponding IPDS/UP³I triplets before they are sent to the printer. Asalready in FIG. 2, the resulting printed documents 28, 29, 30 aregrouped, whereby in the case of FIG. 3 the pages are stapled and shiftedgroup-by-group, and all are shrink-wrapped together in a protectivecovering as this has been specified by the user.

The labeled bars 35, 36 show the respective post-processing steps of theancillary documents.

A user that would like to extend an AFP print data stream withpost-processing functionalities (for example UP³I) with the method shownin FIG. 3 must have the original PPFS control file available andfurthermore have access to the user program that has generated theoriginal print data stream. However, this is not always given. It istherefore a requirement to expand existing AFP print data streams withadditional device functionalities in order to enable an optimallyautomated process for generation of more complex documents withouthaving to access old control files or user programs that were decisivein the generation of the data stream.

To recapitulate, it is to be established that the user must implement atleast the following steps in the method shown according to FIG. 3:

-   -   a) He must change existing copygroups which contain a finishing        operation. Tools such as the computer program PPFA are available        for this.    -   b) He must add new copygroups that are respectively situated at        the beginning of a finishing operation or indicate their        continuation and    -   c) he must modify the print data stream in order to call the        modified or inserted medium maps (copygroups).

The steps cited above are all the more elaborate the larger therespective application, i.e. the more documents that are contained inthe application and/or the more medium maps/copygroups that arecontained in the formdef file. Typical AFP applications are comprised ofmultiple thousands (up to hundreds of thousands) of pages. A typical AFPformdef file contains a plurality of medium maps, for example in what isknown as a mixplex job, in which various paper feeder bays and/orsimplex/duplex print commands alternate within a print job. Effort andsusceptibility to error are therefore very high under the circumstancesgiven the preparation of such print data streams.

Possibilities for insertion of information into a MO:DCA data stream arespecified in U.S. Pat. No. 5,768,488. Furthermore, in the articlePrePress, published 8/99, pg. 18-27, it is specified that the host inputmodule of the program “Hausdruckerei Manager”, vers. 6.1 by the systemvendor Danka allows the addition of information that are not containedin AFP/IPDS data streams, for example commands for duplex printing andend processing.

A method for enhancement of a document data stream with data forperipheral devices is known from DE 100 24 523 A1.

From the document EP-A-1 139 275, it is known to search through a GDIprint data stream for address data that are extracted from this printdata stream. The extracted data are subsequently re-supplied to the datastream.

From the document EP-A-1 156 411, it is known to create an electronicjob ticket with whose help a print data stream is generated fromunprintable data that comprises the templates and text data.

From the document WO 01/77807 A2, a method and system for processing ofa print data stream are known that converts a print data stream of afirst data format into a print data stream of a second standardizedformat.

The previously cited publications and patent applications are herewithincorporated by reference into the present specification.

SUMMARY

It is an object to automate the insertion of finishing operations intoexisting structured document data streams.

In a method and system for enhancement of an input document data streamwhich comprises at least one input format file comprising formatdefinitions and an input document data file structured in at least oneof ranges and sub-ranges and containing variable data, the data streamis enhanced with finishing commands. In a control file, defining levelstructures that correspond to at least one of the ranges and sub-rangesof the input document data file. In a control file, associating thefinishing commands with levels. Using the control file, the input formatfile and the input document data file the following are automaticallygenerated by a computer program module:

-   -   a) an output format file that contains the finishing commands in        callable groups, and    -   b) an output document data file containing the variable data and        group calls associated by at least one of range-by-range and        sub-range-by-sub-range.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a high-capacity printer system;

FIG. 2 shows a conventional technique for processing of a structureddata stream;

FIG. 3 illustrates a conventional technique for propagation of astructured data stream with finishing commands; and

FIG. 4 shows a technique of the preferred embodiment for automatedenhancement of a structured data stream with finishing commands.

DESCRIPTION OF THE PREFERRED EMBODIMENT

For the purposes of promoting an understanding of the principles of theinvention, reference will now be made to the preferred embodimentillustrated in the drawings and specific language will be used todescribe the same. It will nevertheless be understood that no limitationof the scope of the invention is thereby intended, such alterations andfurther modifications in the illustrated device, and/or method, and suchfurther applications of the principles of the invention as illustratedtherein being contemplated as would normally occur now or in the futureto one skilled in the art to which the invention relates.

To enhance with finishing commands an input document data stream thatcomprises at least one input format file containing format definitionsas well as an input document file structured in ranges and/or sub-rangesand containing variable data, it is provided that a control file isapplied in which the level structures are defined that correspond to theranges and/or the sub-ranges of the input document file. Furthermore, inthe control file the finishing commands are associated with the levels,such that the following files can be automatically generated with acomputer program module using the control file, the input format fileand the input document file:

-   -   (a) an output format file that contains the finishing commands        in callable groups, and    -   (b) an output document file containing the variable data and        group calls associated range-by-range or sub-range-by-sub-range.

One advantage of the preferred embodiment with regard to conventionalmethods is that the user does not need to modify existing printproduction jobs himself. In particular AFP applications can generateprint data entirely independent of the site and the type of theirprintout. Additional finishing commands for devices for pre- orpost-processing of print goods in the print production process areextended in a data enhancement process with new or existing print datastreams, which in particular can occur in a production-in-time eventjust before the print job is actually processed. Via the automation ofthe event to the greatest possible extent, a data enhancement processcan be rapidly triggered, whereby the process speed can be between10,000 and 50,000 pages per minute. A complete, immense print job canthereby be prepared within only a few minutes, such that it can fully orpartially use the capabilities of a print production path with complexdesign. In addition to the enhancement of print data with finishingcommands, the data can be enhanced (in particular via the same computerprogram module) with further control data more or less independent ofthe print path, for example with franking data for postal shipments orwith barcode data for detection of generated documents in later methodsteps. For this, the preferred embodiment can in particular be combinedwith the method or system of the previously cited PCT/EP02/05299 inwhich, in a method, system or computer program for processing of adocument data stream, a series of function stages are used in order toenable a fast, secure output of the documents in a productionenvironment, in particular in a print production environment. Thecontent of this patent application is herewith again explicitlyreferenced.

The preferred embodiment is based on the realization that, in astructured input data stream that should be enhanced with complexfinishing commands, the existing document structure can be utilized, andvia allocation of ranges or sub-ranges of the document data stream, acorresponding association of finishing commands range-by-range ispossible. According to a further aspect of the preferred embodiment, forallocation a control file is provided in which document levels on whichspecific finishing commands should be applied are defined independent ofthe concrete structure of the document input file. This event can thusbe automated very well and in particular be automatically prepared forlarge to very large print data streams (for example print data streamscontaining thousands to millions of documents).

A user who wants to expand a resource-structured document data streamwith finishing operations is provided with a tool (computer program,editor) with which he can specify the finishing operations that are tobe implemented. Parameters that more precisely specify the operation canhereby be provided. Furthermore, the user can specify the location andthe range (or the levels) within the variable print data stream in whichthe finishing operation is to be applied. Furthermore, the necessaryfinishing commands (copygroups, medium maps) are automatically insertedinto the format definition file (formdef) by a computer program module.Finally, the processing calls (medium map invocation) contained in thedocument data file containing variable data are modified or insertedsuch that the finishing operations (copygroups) incorporated into theformat definition file are invoked instead of the original callscontained in the variable document data file.

Due to the high degree of automation of the replacement of priorprocessing calls with the supplemented calls with additionalfunctionalities, errors are largely to be eliminated. Existing processesfor generation of document data do not need to be modified. Since theuser only needs to specify the new available finishing operationcommands on a relatively simple interface (editor, graphical userinterface GUI, computer program) and the insertion of correspondingcalls into the document data file occurs automatically, even verycomplex and large document data files can be adapted to the newpossibilities in the range of the pre-processing and post-processing ofprint goods with only slight effort of the operator.

In a preferred exemplary embodiment, the input document data streamsand/or the resource-structured output document data stream are anAdvanced Function Presentation™ data stream. With the preferredembodiment, it is thereby in particular possible to enhance other inputdocument data streams such as, for example, line data, PCL data orPostscript data with finishing commands, if applicable to take overfinishing commands already integrated there or to overwrite and/or togenerate finishing commands on the output side in an Advanced FunctionPresentation™ data stream. It can be provided just as well in thereverse, that on the input side an Advanced Function Presentation™ datastream exists and this is to be converted at the output side into adifferent resource-structured output data stream.

A document print production system 1 is shown in FIG. 1 that on the onehand comprises a mainframe architecture 2 and on the other handcomprises a network architecture 5 in which document data or a documentprint data stream are respectively generated by means of user programs(tools). In the mainframe architecture, these print data are generatedby a host computer 3, in particular as an AFP print data stream or as aline print data stream. The print data can alternatively be transferreddirectly from the host computer 3 to one or more print devices 6 a, 6 bvia what is known as an S/370 channel 14 a. As an alternative to thisoutput channel, the print data can also be transferred from the hostcomputer 3 to a processing computer 4 via a network 13 or a direct dataconnection 14 b, in which processing computer 4 the print data arebuffered (for example in an associated file server) and processed forsubsequent output steps. In such host computers 3, in particular printdata streams are generated that are assembled from larger data stocks(databanks) of regular list expressions, calculations, consumptionoverviews (for telephone accounting, gas accounting, bank accounts),etc. Such applications have frequently already been in use for manyyears and, as before, are necessary in a more or less unchanged manner(what are known as legacy applications).

The print production workflow is monitored by a monitoring system 7within the mainframe architecture 2. The monitoring system 7 comprises amonitoring computer 7 a that is coupled with a databank 7 b and containsvarious computer program modules 7 c (compare FIG. 2).

The monitoring system 7 is connected with the host computer 3 via adevice controller network 15 and a print manager module 8 as well as viaa converter 9 with a V24 data line that connects to both of the printdevices 6 a, 6 b. The converter 9 converts the V24 signals into DMIprotocol signals of the device controller network 15. SNMP protocolsignals can be provided to the device manager DM converted as DMIprotocol signals or can be directly passed as SNMP protocol signals.

Print product 19 that has been generated in the printers 6 a, 6 b fromthe document print data stream and on which barcodes are printed can berespectively scanned with a manually movable, radio-controlled barcodereader 11 a. The signals are transferred via radio to the read station10 a and transferred into the device controller network 15 or to themonitoring system 7. Readers for one-dimensional and/or two-dimensionalbarcode systems can be used as barcode readers, such that variousbarcode systems can be read with one and the same read device. Thebarcode reader system is in particular configurable, i.e. adaptable tovarious application-specific codes or the respective suitable controlmethods.

Document data are generated in the network architecture 5 by means ofuser programs in client computers 12, 12 a that are connected among oneanother via a client network 13 as well as with the processing computer(file server) 4. The file server thus serves as a central handling andprocessing interface for print data of the entire print productionsystem 1. Diverse control modules (software programs) run on it, viawhich control modules the entire print production workflow or the entiredocument processing is optimally adapted to the respective conditions ina manner that is application-specific, production-related and takesplace at the device controller.

In particular the following functions, which are specified moreprecisely in connection with subsequent Figures, are executed in thefile server:

1. Converting Indexing Sorting

In this function, incoming print data are converted into a uniform dataformat, indexed according to predetermined parameters and re-sorted in apredetermined sorting sequence. This in particular enables there-sorting of the data streams optimized for the subsequent documentoutput, for example the merging of various pages that are not insuccession in the input data stream to be sorted together into a mailpiece, such that they can, for example, be enveloped together into acorrespondence (for example in an enveloper 22 b).

2. Insertion of Control Information

In this function, control information, in particular barcodes, areinserted into the data stream, using which control information a datagroup belonging together (for example page, sheet, document, mail piece)can be recognized as such and be unambiguously localized in theproduction process at the various processing stations.

3. Data Reduction

With this function, control data that have been delivered in the inputdata stream from the host computer 3 or user computer 12 to theprocessing computer 4 can be filtered to the effect that such controldata that are not necessary in the given overall system arrangement areremoved. Via the connection of all participating output devices (printer6 a through 6 d, cutter 22 a, enveloper 22 b) via the device controllernetwork 15, it can already be decided in the processing computer 4 whichcontrol data of the input data stream are needed by none of theconnected devices. Via removal of this data from the data stream, thedata stream can be reduced overall, in particular when only empty fieldentries regarding corresponding control data are contained in the inputdata stream.

4. Extraction

With this function, predetermined data can be filtered or separated outfrom the output data stream, whereby a compressed data stream(compressed data) is created, in particular for control and status datathat can be exchanged with very high speed between the participatingdevices and the monitoring computer. It is thus possible to execute themonitoring of the participating devices in real time.

The functions 1.-4. can largely be automatically implemented by acomputer program module “CIS” (Converting, Indexing and Sorting), whichis gone into again in detail later.

Repeated Print (Reprint)

When, in the course of the further processing of the data, in particularin the output of the data on one of the print devices 6 a, 6 b, 6 c or 6d, an error occurs in one of the post-processing devices 18 a, 18 b oralso in the print computer 16, this can be determined by the monitoringsystem 7 using the control barcodes inserted into the processingcomputer 4, and the reprint of the documents (pages, sheets, mailpieces) affected by the fault can be requested. This reprint request isdecisively controlled in the processing computer 4.

Print data that have been completed by the processing computer 4 areconveyed via the print data line 14 c to a print server 16. Its task isessentially to unload the processing computer 4. This occurs viabuffering of the completed print data until its recall via the data line14 d to one or both printers 6 c, 6 d. The print server 16 is thusintegrated into the overall system predominantly for reasons ofperformance (speed). In systems whose print speed is less high, theprint server 16 can also be foregone.

Document data that are transferred to the printers 6 c or 6 b and thereare printed on a recording medium (for example paper) are, in theoverall system, supplied to further processing steps, namely the cutter18 a and the enveloper 18 b of the further processing. The printproduction process is therewith concluded.

The printed documents are tested with a test system 17 with regard tovarious criteria on their processing path between the print device 6 andthe last post-processing device 18 b, namely via an optical test system17 a with regard to their optical print quality, with a barcode testsystem 17 b with regard to their existence, their consistency and/ortheir sequence, as well as with an MICR test system 17 c insofar as theprint was printed by means of magnetically-readable toner (magnetic inkcharacter recognition toner). The data of the various test systemsprovided by the test system 17 are transferred from a mutual, serialdata acquisition module (serial delta acquisition module) 17 d to thedevice controller network 15 and supplied to the monitoring system 7.There the respective system data are acquired and the devices arechecked in real time, and the respective positions of the documents aretested with regard to their correctness relative to the print job.

Further details of such a test system 17 are specified in the U.S. Pat.No. 6,137,967 or in the patent application corresponding thereto. Thecontent of this patent or these patent applications are herewithincorporated by reference into the present specification.

The finished printed documents 23 can in turn be registered with abarcode reader 11 b that is connected, radio-controlled, with anassociated control device 10 b, which in turn delivers its data to themonitoring system 7 via the device controller network 15.

Using the input print data file 22 and the input formdef file 23, whichhave already been the basis for the specifications of FIGS. 2 and 3, inFIG. 4 it is shown how an output print data stream is generated in thedata format AFP. For this, it is initially helpful once to consider thedata structure in the input print data file 22 in more detail. With thebracket 40, all data of the print data file, the largest coherent rangeof the print data from the command “beginning of job” to the command“end of job”, are bracketed. The AFP print data stream is then dividedup into subsequent sub-ranges that respectively signal more or lesslarge documents belonging together such as, for example, mail pieces orpages. The preferred embodiment utilizes this range-oriented structure.In the example of the print data file 22, a first range is opened viathe command “BNG Customer” and closed via the command “ENG Customer”.Bracket 41 shows this range. Within this range, there are sub-ranges“Account” that are respectively begun or ended via the commands “BNGAccount” and “ENG Account”; see brackets 42 and 43. Within the accountrange, various pages are then respectively structured in turns with thecommands “BP” and “EP” for beginning of the page and end of the page.

The second customer range that is designated with the bracket 44 islocated on the same hierarchy level as the customer commands, which weredesignated with the bracket 41. It also has a sub-region “Account” thatis comprised by the bracket 45. In order to also map this data structureof the print data file in the control file 46, their levels are definedwith the commands “Define level”. The highest level (Level_A) is thusthe entire print data file 22 that is encompassed with bracket 40. Thehighest range (Customer) of the print data file 22 is subdivided into afirst customer range that is encompassed with bracket 41 and a secondcustomer range that is encompassed with bracket 44. Corresponding to thedesired processing schema for the documents stored there (see FIGS. 1and 2), whereby the documents of the first customer should be offset tothe left and the documents of the second customer should be offset tothe right, two different levels must be defined within this range levelin the control file 46, namely one level that corresponds to alluneven-numbered calculations within the first group level (see alsocustomer bracket 41) and a second level that corresponds to alleven-numbered calculations within the group level 1 (compare also secondcustomer bracket 44).

Finally, in the control file 46 the various finishing operations areassociated with the previously-defined levels: in the example of FIG. 4,the level “Level_A” with the finishing job “Shrink”, the level“Level_B1” with the finishing job “Left/Shift” and the level “Level_B2”with the finishing job “Right/Shift” and the level “Level_C” with thefinishing job “Staple”.

The control file 46 completed in step S7 contains three data ranges,namely a first data range 47 in which are defined the various finishingoperations that can be executed by print pre-processing orpost-processing devices, a definition range 48 for levels in which aredefined various levels of the structured input data stream 22, and adevice range 49 for the associations that should be made between thefinishing operations 47 and the defined levels 48 or which finishingoperation commands should be inserted into which levels of thestructured data stream file 22. As soon as the user has completed thecontrol file 46, with the CIS computer program module 50 in step S9 anew formdef file 51 can be automatically created from the print datafile 22, the formdef file 23 and the control file 46, and in step S10 anew print data file 52 can be simultaneously generated. The newcopygroups LI_ACC1, LI_ACC2 and RI_ACC1 are generated from the formdeffile 23 and the finishing operations specified in the control file 46.Furthermore, the CIS computer program module 50 effects that themodified print data file is generated from the print data file 22 andthe definition range 48 for levels as well as the definition range 49for associations. For this, the CIS computer program module 50 (CISstands for Converting Indexing and Sorting), see also the specificationregarding FIG. 1), examines the input print data file 22 with regard toits logical, hierarchical structure and assigns the levels to thevarious data ranges, i.e. the level Level_A to the entire documentcorresponding to the bracket 40, Level_B1 to the data range of thebracket 41, etc. Using this association and the associations made in thedefinition range 49, corresponding finishing commands that have beendefined in the range 47 can be inserted into the print data file 22 atexactly the right positions, such that the print data file 52 iscreated. The CIS computer program module 50 thus uses the informationthat are contained in the control file 46 and modifies the medium maps“Account” that were contained in the original formdef file 23 and theircorresponding calls in the original print data file 22 “IMM Account” andmodify these corresponding to the henceforth refined, additionalfinishing commands. The conversion occurs automatically via the CIScomputer program module 50 and thus guarantees an inherently logicalresult tuned or synchronized to one another.

The resulting new formdef file 51 contains new medium maps, whereby thedesignations “LI_ACC1”, etc. are purely voluntary and can be completelyautomatically as well as randomly generated by the CIS computer programmodule. However, a designation assigned once is then retained. In allcases, the new medium maps replace the preceding ACCOUNT medium maps ofthe original formdef file 23.

Further details of the CIS computer program module 50 can be learnedfrom WO 01/77807 A2 and PCT/EP02/05299, which is herewith againexplicitly incorporated into the present specification. An importantfunctionality of the CIS computer program module 50 that is addressed inthe older WO publication '807 is the normalization of the data of theinput print data file 22. It is converted and, if applicable, re-sortedin step S10 such that identical job types and/or identical customers aremutually printed out in succession, such that the subsequent processingof the documents (stacking, enveloping, stapling, etc.) is simplified.

The modified print file 52 and the modified formdef file 51 are suppliedin step S11 to a host printer driver 24 that conveys the AFP data streamin an APDS data stream to an IPDS- and UP³I-capable printer. The UP³Icommands that are contained in the medium maps are converted intocorresponding IPDS triplets before they are sent to the printer (stepS11).

As already in FIGS. 2 and 3, in the exemplary embodiment of FIG. 4 theprint good generated with the method is also comprised of five pages forcustomer 1 and its first account, three pages for the second account ofthe customer 1 and two pages for the customer 2. This time, the pagesare stacked, shifted and film-welded as this has been requested by theuser.

Due to the structural correspondence between input file 22 and controlfile 46, the effort to introduce auxiliary device functionalities (suchas UP³I functions) into an existing application of a resource-structuredprint data stream is relatively small. Via the automation, a secureconversion can occur independent of the size of the application (numberof the documents, pages and/or mail pieces) and the number of the mediummaps in the form definition file. Furthermore, the specifications of theoriginal form definition file 23 are not necessary, such that the AFPuser that wants to implement a UP³I data extension does not need anyaccess to the original control file with which the original formdef file23 was generated. An AFP user who wants to implement additional devicefunctionalities in the data stream also needs no access to an originalPPFA control file or to the application program that has originallygenerated the data stream, because he only inserts the additionalcommands into the data stream, including the formdef file 23, on acomfortable operator interface.

In step S11, the modified print data file 52 and the modified formdeffile 51 are converted by the host printer driver 24 into an IPDS datastream, and this IPDS print data stream is output to the printing system25 for output. In step S12, this produces three documents 28, 29 and 30as they have already been explained in detail using FIGS. 2 and 3.

In the exemplary embodiments cited above, AFP print data haverespectively been enhanced with finishing commands in order to subjectdocuments to a print pre-processing and/or a print post-processing invarious manners. However, the preferred embodiment is suitable not onlyfor AFP print data streams or corresponding resource-structured inputfiles but rather can, for example, also be applied for what is known asline data that are inherently unstructured. By means of a suitablecomputer program module, for example the known computer program ACIF bythe company IBM or the computer program “CIS” 50 already used in thepresent embodiment, which is also explained in detail in WO 01/77807,such line data can be converted such that the line file is convertedinto a structured file by means of what is known as a pagedef file. Thisstructured file then corresponds to the print data file 22 of theexemplary embodiments illustrated above and can in turn, by means of acorresponding formdef file 23, be automatically converted with thepreferred embodiment into an output file 52 enhanced with finishingcommands.

In addition to line data, Extendable Markup Language data (XML data) canalso be enhanced with finishing operations. The XML standard isprimarily a well-known standard in the field of Internet pages.Personalized Printer Markup Language data (PPML data) can also beenhanced with finishing commands with the present invention. Finally, itis also possible to process further known types of document data streamssuch as, for example, data of the Printer Control Language (PCL) in themanner of the preferred embodiment. Finishing commands can thus alreadybe contained in the original data stream (PCL), the PCL data stream canbe converted into an AFP data stream and the already-existing finishingcommands can thereby be adopted and optionally enhanced with additionalfinishing commands. The enhancement then occurs in the manner of thepreferred embodiment.

Finally, with the preferred embodiment it is also conceivable to effecta data reduction instead of a data enhancement, i.e. to reduce a printdata input file that contains finishing operations by these operations.The fundamental workflow of the preferred embodiment, with the creationof a control file that defines specific levels and assigns certainfinishing operations to these levels, is thereby maintained. Only theremoval of finishing commands is established instead of the addition offinishing commands. It can just as well be provided to exchangefinishing commands, whereby, for example, finishing commands that set upon a specific type or a specific version of finishing device, are to bereplaced by correspondingly changed types or versions. This can inparticular be advantageous when a file to be printed contains finishingcommands of a specific standard (for example UP³I) and should beprocessed on a system that does not fulfill this standard, for exampleis not UP³I-capable. Furthermore, the preferred embodiment enablesfinishing commands or data of a first standard to be replaced byfinishing commands or data of a second standard, for example when anapplication should run on a new system.

With the preferred embodiment, the fundamentals are achieved to veryflexibly deal with print data streams in more or less complex printproduction systems in which the data, documents, or recording media areprocessed in a plurality of devices.

Given the conversion of a PCL or PS (Postscript) data stream into AFP,it can additionally be provided that the formdef file is created in acourse with the conversion of the print data file, i.e. it is formed “onthe fly”, so to speak. The modified print data file and the modifiedformdef file for processing of the print job in a printing system withfinishing commands can then directly and very quickly occur with both ofthese files (formdef file and print data file) and the inventive controlfile generated by the user.

The preferred embodiment can in particular be realized as a computerprogram (software). It can therewith be distributed as a computerprogram module, as a file on a data medium such as a diskette or CD-ROM,or as a file via a data or communication network. Such and comparablecomputer program products or computer program elements are embodiments.The procedure of the preferred embodiment can be used in a computer, ina print device and/or in a printing system with upstream or downstreamdata processing devices, in particular when the computer program runs ona suitable computer and there effects a method procedure of thepreferred embodiment. It is thereby clear that corresponding computerson which the preferred embodiment is used can comprise further knowntechnical devices such as input devices (keyboard, mouse, touchscreen),a microprocessor, a data or control bus, a display device (monitor,display) as well as a working storage, a fixed disc storage and anetwork card.

While a preferred embodiment has been illustrated and described indetail in the drawings and foregoing description, the same is to beconsidered as illustrative and not restrictive in character, it beingunderstood that only the preferred embodiment has been shown anddescribed and that all changes and modifications that come within thespirit of the invention both now or in the future are desired to beprotected.

1-24. (canceled)
 25. A method for enhancement of an input document datastream which comprises at least one input format file comprising formatdefinitions and an input document data file structured at least one ofin ranges and sub-ranges and containing variable data, comprising thesteps of: enhancing the data stream with finishing commands; in acontrol file defining level structures that correspond to at least oneof the ranges and the sub-ranges of the input document data file; in thecontrol file associating the finishing commands with the levelstructures; and using the control file, the input format file and theinput document data file, automatically generating by a computer programmodule an output format file that contains the finishing commands incallable groups, and an output document data file containing thevariable data and group calls associated by at least one ofrange-by-range and sub-range-by-sub-range.
 26. A method according toclaim 25 wherein in the control file the finishing commands and thelevels are defined and it is registered which finishing commands areapplied in which level.
 27. A method according to claim 26 wherein inthe control file it is established which processing commands areexecuted on which levels.
 28. A method according to claim 25 wherein thedocument processing system comprises a data production system thatcomprises a printing device and at least one device for processing of aprint product at least one of before and after the printing event, andwherein the finishing commands activate at least one of the devices forprocessing of the print product at least one of before and after aprinting event.
 29. A method according to claim 25 wherein the data ofthe output format file and the data of the output document file aregenerated corresponding to one another with the computer program module.30. A method according to claim 25 wherein at least one of aresource-structured input document data stream and a resource-structuredoutput document data stream comprises an Advanced Function Presentation™data stream.
 31. A method according to claim 25 wherein at least one ofa resource-structured input document data stream and aresource-structured output document data stream comprises at least oneof an XML, PPML, PCL and PostScript data stream.
 32. A method accordingto claim 30 wherein the input and output format definition files arerespectively a formdef file, and the computer program module providesthe output formdef file with modified medium maps relative to the inputformdef file.
 33. A method according to claim 30 wherein the outputdocument file comprises a print file with variable print data, and thecomputer program module enhances the variable data with calls of mediummaps of the output formdef file.
 34. A method according to claim 25wherein a non-resource-structured file is read in and converted into aresource-structured input data file.
 35. A method according to claim 34wherein the non-resource-structured file comprises a line data file. 36.A method according to claim 34 wherein the same computer program moduleas is used to prepare the resource-structured input file is used toconvert the non-resource-structured file.
 37. A method to change orremove finishing commands in an input print data stream which comprisesat least one input format file comprising format definitions and aninput document data file structured in at least one of ranges andsub-ranges and containing variable data, comprising the steps of: in acontrol file defining level structures that correspond to at least oneof the ranges and the sub-ranges of the input document data file; in thecontrol file associating modified finishing commands with the levelstructures; and using the control file, the input format file and theinput document data file automatically generating by a computer programmodule the following an output format file that one of contains thefinishing commands in callable groups and that no longer containsremoved finishing commands, and an output document data file containingthe variable data and group calls associated by at least one ofrange-by-range and sub-range-by-sub-range.
 38. A computer programproduct that enhances an input document data stream with finishingcommands, comprising: at least one input format file comprising formatdefinitions and an input document data file structured in at least oneof ranges and sub-ranges and containing variable data; in a control filelevel structures are defined that correspond to at least one of theranges and the sub-ranges of the input document data file; in thecontrol file the finishing commands are associated with the levelstructures; and using the control file, the input format file and theinput document data file, the following are automatically generated by acomputer program module: an output formal file that contains thefinishing commands in callable groups, and an output document data filecontaining the variable data and group calls associated by at least oneof range-by-range and sub-range-by-sub-range.
 39. A computer programproduct according to claim 38 wherein in the control file, the finishingcommands, and the level structures are defined and which finishingcommands are applied in which level structure is registered.
 40. Acomputer program product according to claim 39 wherein in the controlfile it is established which processing commands are executed on whichlevel structures.
 41. A computer program product according to claim 38wherein the document processing system comprises a data productionsystem that comprises a printing device and at least one device forprocessing of a print product at least one of before and after theprinting event, and wherein the finishing commands activate at least oneof the devices for processing of the print product at least one ofbefore and after a printing event.
 42. A computer program productaccording to claim 38 wherein it is suitable to process an AdvancedFunction Presentation™ data stream as at least one of aresource-structured input document data stream and a resource-structuredoutput document data stream, a computer program module providing anoutput formdef file with modified medium maps relative to an inputformdef file, and the output document file comprises a print file withvariable print data and the computer program module enhances thevariable data with calls of the medium maps of the output formdef file.43. A system for enhancement of an input document data stream withfinishing commands, the input document data stream comprising at leastone input format file comprising format definitions and an inputdocument data file structured in at least one of ranges and sub-rangesand containing variable data, comprising: in a control file levelstructures are defined that correspond to at least one of the ranges andthe sub-ranges of the input document data file; in the control file thefinishing commands are associated with the level structures; and acomputer program module is provided via which, using the control file,the input format file and the input document data file, the followingare automatically generated: an output format file that contains thefinishing commands in callable groups, and an output document data filecontaining the variable data and group calls associated by at least oneof range-by-range and sub-range-by-sub-range.
 44. A system according toclaim 43 wherein in the control file the finishing commands and thelevel structures are defined and it is registered which finishingcommands are applied in which level structure.
 45. A system according toclaim 44 wherein in the control file it is established which processingcommands are executed on which level structures.
 46. A system accordingto claim 43 wherein a document processing system comprises a dataproduction system that comprises a printing device and at least onedevice for processing of a print product at least one of before andafter a printing event, and wherein at least one of the devices isdesigned such that it interprets the finishing commands for processingof the print product at least one of before or and after the printingevent.
 47. A system according to claim 43 wherein a device is providedto receive a resource-structured input document data stream and isdesigned such that it at least one of interprets and processes anAdvanced Function Presentation™ data stream.
 48. A system according toclaim 43 wherein a device is provided to receive a resource-structuredinput document data stream and is designed at least one of such that itinterprets processes at least one of an XML, PPML, PCL, and PostScriptdata stream.